1. Field of the Invention
The present invention relates to operating systems for computers. More particularly, the invention concerns loading basic input/output system (BIOS) into RAM as part of the boot sequence, as opposed to having such pre-stored in ROM.
2. Description of the Related Art
Modern computing architectures typically define a pre-execution environment that among other things specifies the boot sequence to be used to initialize a computing system. The pre-execution environment typically defines specific physical address spaces in the memory system where specific computer instructions are expected to reside.
For example, the pre-execution environment may specify that computer instructions to perform power-on self test (POST) for the processor should exist at certain memory addresses. These instructions are stored in non-volatile memory (e.g., ROM) so that the instruction will exist in memory, ready for execution, upon power up of the processor.
In addition, the pre-execution environment may specify that certain instructions to provide basic input/output services (BIOS) should exist at certain memory addresses. These instructions are likewise stored in non-volatile memory (e.g., ROM or flash). The BIOS provides basic I/O services to certain peripherals and are needed to initialize the computing system. For example, as will be explained in more detail below, to initialize the system, the boot sequence code needs to read an operating system image from a boot device (e.g., local disk) and store such in computer memory so that it may be used for execution; to read such image from the boot device, the boot sequence code needs the basic input/output service for reading information (i.e., the operating system image) from a peripheral such as a disk; the BIOS provides such service.
FIG. 1 depicts an exemplary, conventional standard PC Boot/install process, such as with Windows. As depicted, once the processor is powered on, it will automatically start to read and execute the instructions at predefined memory addresses, i.e., the addresses having the processor initialization code and POST instructions 101. This stage of boot will also contain very rudimentary instruction to go to a boot device and read a special program called an OS loader (or for some systems, it will read in the DOS operating system). To do such reading, the boot stage 1 instructions need the BIOS run time services 107 to access the associated boot device 111.
Thus, at boot stage 1, the POST and BOOT sector load stage 101 uses the BIOS including BIOS run time services 107 to load DOS or the operating system loader from local hardware 111, e.g., a local CD or floppy disk into the processor. Once the OS loader (or DOS) is loaded into processor memory, at boot stage 2, the boot sequence transfers program control to the just-loaded image (e.g., OS loader). The processor then starts executing the instructions just loaded. These instructions continue to read and load other portions of the operating system. This stage is known as a BIOS dependent stage 103, because the instructions are still using the BIOS run time services 107 to provide the instructions to read the operating system and other software from peripherals 111. At some point in the sequence, device drivers for peripherals get loaded into memory. After such a point, the boot sequence can transfer control to subsequent driver-dependent stage of boot 105. This stage may then use the device drivers 109 to perform I/O to the peripherals and to complete the boot process for the system. By using the device drivers 109, the driver dependent stage may potentially access peripherals not supported by BIOS or use peripherals supported by BIOS in a more efficient and reliable way. Once the system is booted, applications may then execute using the operating system and drivers as needed. BIOS typically is not used once the boot sequence is complete, though there are exceptions (more below).
Though the above boot sequence and approach is well known and common, it has certain disadvantages. Two disadvantages are discussed below.
First, it is cumbersome to modify the BIOS to fix bugs or otherwise improve the code. The BIOS is loaded into flash or ROM memory. To update the BIOS (in flash) normally the computer must be powered down and a special program needs to be run to update the BIOS image. To update the BIOS in ROM is even more difficult.
Second, some processing platforms do not provide the supported boot devices and thus need to utilize different approaches to booting. For example, the Egenera BladeFrame™ processing platform allows an administrator to configure (under software control) at least one virtualized processing area network (PAN) system having one or more inter-communicating processors, each without a local disk or other boot device of any type. Thus the conventional sequence of FIG. 1 will not work, as the Boot sector load stage and BIOS dependent stage will fail.
To address its unique architecture, the BladeFrame™ processing platform uses a boot sequence like that shown in FIG. 2. The processor executes POST instructions analogous to the situation depicted in FIG. 1. However, rather than use BIOS run time services to access a boot device, the processor uses an approach involving Option ROM 204. The Option ROM 204 is accessed in a conventional way. The Option ROM 204 includes instructions to download a program from a remote device (e.g., using TFTP) and then transfers execution control to that program. The program in this case includes computer instructions to download the operating system image including special device drivers that include emulation code to emulate local peripherals with remote devices (i.e., the emulation code communicates requests over the communication fabric 206 to a remote device 211, which serves the request). The boot sequence avoids the BIOS dependent stage of FIG. 1 and proceeds to a driver dependent stage to complete booting. Thus, the approach completely avoids the use of BIOS run time services.
While the approach of FIG. 2 works, it imposes certain limitations on the system. There are some applications that expect to use BIOS run time services for operation (e.g., many operating system loaders). In addition, some operating systems expect BIOS to be present and use the BIOS runtime services even during normal (non-boot) operation.
With regard to the approach of FIG. 2, the system must be powered down and rebooted from an alternate device, typically a floppy. The operation to update the BIOS is risky as the current BIOS will be destroyed in the process of updating and any failure during that update will result in a system that is unbootable.
Consequently, there is a need for a system and method of providing a BIOS solution that addresses the above shortcomings.